The present invention generally relates to data processing. The invention relates more specifically to methods and apparatus of using a single computer program code base to provide a program that is operable in either a client-server mode or a standalone mode.
Development of a new computer software application program often requires an early and fundamental design decision, namely whether to structure the program as a stand-alone program or as a client-server application. Stand-alone programs normally support use by a single user who communicates with one instance of the program at any given time. Client-server applications generally comprise a server software element that can receive and support multiple connections from multiple concurrent users or client software elements. Client-server architecture is increasingly popular because it is naturally suited to technologies such as the World Wide Web, in which browser client programs receive service from a remotely located server. In client-server model the browser client may execute a client side applet that communicates with a server side program.
Stand-alone programs are more simple to develop and operate, but lack flexibility and scalability. Client-server applications offer the advantage of central control, and can use and build upon proven and standardized client technologies such as Web browsers. However, client-server applications are far more complicated to develop, deploy, and maintain. Further, the server element represents a single point of failure, which is undesirable in some systems. More information about client-server computing is disclosed in R. Orfali et al., xe2x80x9cClient/Server Survival Guidexe2x80x9d (New York: John Wiley and Sons, Inc.), 3d Ed. 1999.
Accordingly, some application programs are designed in both a standalone version and a client-server version. A challenge involved in the development of such programs is how to structure the computer program source code that makes up both versions (the xe2x80x9ccode basexe2x80x9d) in a way that both versions can be supported without unacceptably high development and maintenance costs.
In one approach to this problem, two (2) separate code bases are maintained, one for the standalone version of the application program and another for the client-server version. This approach requires different versions for some of the code as well as duplicating common code in each code base. When this approach is implemented in the Java(copyright) language, another drawback of this approach is that the two versions of executable code (xe2x80x9ccode imagesxe2x80x9d) cannot coexist in the same runtime tree, since they have the same package paths and class names. This would result in conflicts and errors in compilation, interpretation or execution. (Java(copyright) is a trademark of Sun Microsystems, Inc.)
In an alternative approach, one (1) code base is used, with two (2) versions of certain interfaces between client side logic and server side logic. At run time, a portion of the client code would determine whether the currently executing version is the stand-alone version or the client-server version. Based on such determination, a corresponding version of the interfaces is selected. A disadvantage of this approach is that the version specific code is mixed in the same physical files, and one final code image is produced for both versions. As a result, the mixed version specific code is difficult to maintain as the interfaces grow, and it is difficult to debug. The decision and selection process also introduces unnecessary overhead at runtime.
In yet another alternative approach, one (1) code base is used, and compiler condition directives are used to separate version-specific code at compile time. For example, the xe2x80x9ccppxe2x80x9d compiler condition directive may be used to instruct the compiler to selectively compile portions of the source code depending on whether the stand-alone version or client-server version is being compiled. However, this approach requires the compiler directives to be placed in each file that has version-specific logic. This includes all the interface files between the client side logic and the server side logic. This also makes the code difficult to maintain. As in the first approach described above, when this approach is implemented in the Javag language, another drawback is that the two versions of code images cannot coexist in the same runtime tree, since they have the same package paths and class names. This would result in conflicts and errors in compilation, interpretation or execution.
Based on the foregoing, there is a clear need for a way to structure a code base in order to support both a stand-alone version of an application program and a client-server version.
Ideally, a single computer program code base could provide a program that is operable in either a client-server mode or a standalone mode.
There is a particular need for a method and approach that is useful in the Java(copyright) program development environment.
A method and apparatus for using a single computer program code base to provide a program that is operable in either a client-server mode or a standalone mode are provided. According to one aspect, the invention provides a method of operating a software application in either a client-server mode or a standalone mode using one software code base. Client logic and server logic are created and stored within the one software code base. One or more service objects are created that implement one or more interfaces among the client logic and the server logic. For each of the service objects, a corresponding proxy object is created and stored. A standalone version of the software application that includes the service objects is created and stored. In the standalone version, the client logic invokes the server logic through the interfaces, which are implemented by the service objects.
One feature of this aspect involves creating and storing a client-server version of the software application that includes the service objects and the proxy objects, in which the client logic invokes the server logic through the interfaces, which are implemented by the service objects. In another feature, the method further involves receiving an invocation of a server logic method from the client logic at one of the proxy objects; forwarding the method invocation to a servlet element; and identifying and invoking a corresponding method of one of the service objects that corresponds to one of the proxy objects.
According to another feature, the method includes the steps of serializing parameters of the invocation of the server logic as part of invoking the corresponding method. Another feature involves receiving a result of the service object invocation in the form of a second proxy object; serializing result parameters of the second proxy object into the first proxy object; returning results to the client logic via the proxy object.
In one specific embodiment, a client logic element has one or more proxy objects, each of which implement an interface that is neutral with respect to the client-server mode and the standalone mode. A server logic element has one or more service objects. Each of the service objects implements the interface. The interface implementations are not bound to any code that is specific to the client-server version or the standalone version. In the stand-alone version, the client side logic invokes the server side logic directly through the interfaces, as implemented by the service objects. In the client-server version, the client side logic invokes the server side logic through the same set of Java interfaces. However, the interfaces are implemented by the proxy objects, which internally implement a transport mechanism to forward the method invocation and parameters to the server side through a servlet API. In response, a servlet identifies the corresponding service object and invokes the corresponding method with serialized parameters. When the method returns, the resulting object, which can be a new proxy object, is serialized back into the proxy object for the invocation and from there the result is returned to the client side logic. Using this mechanism, the client side logic only interacts with the Java interfaces, without the need to know whether it is dealing with service objects or proxy objects. Accordingly, the client side logic is shielded from any version-specific code. In addition, the same runtime environment can support both the client-server version and the standalone version.
Other aspects and embodiments relate to a multi-mode network management application program, and to a computer-readable medium that is configured to carry out the foregoing steps.